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Abstract 


The MPLS Transport Profile (MPLS-TP) is based on a profile of the 
MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic 
Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) 
architectures developed by the Internet Engineering Task Force 


(IETF). The International Telecommunication Union Telecommunication 
Standardization Sector (ITU-T) has specified a Transport Network 
architecture. 


This document provides a thesaurus for the interpretation of MPLS-TP 
terminology within the context of the ITU-T Transport Network 
Recommendations. 


It is important to note that MPLS-TP is applicable in a wider set of 
contexts than just Transport Networks. The definitions presented in 
this document do not provide exclusive or complete interpretations of 
MPLS-TP concepts. This document simply allows the MPLS-TP terms to 
be applied within the Transport Network context. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7087. 
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Introduction 


The MPLS Transport Profile (MPLS-TP) has been developed by the IETF 
to facilitate the Operations, Administration, and Maintenance (OAM) 
of Label Switched Paths (LSPs) to be used in a Transport Network 
environment as defined by the ITU-T. 


The ITU-T has specified a Transport Network architecture for the 
transfer of signals from different technologies. This architecture 
forms the basis of many Recommendations within the ITU-T. 


Because of the difference in historic background of MPLS, and 
inherently MPLS-TP (the Internet) and the Transport Network (ITU 
Telecommunication Sector), the terminology used is different. 


This document provides a thesaurus (the analogy to the Rosetta Stone 
has been used within the working groups) for the interpretation of 
MPLS-TP terminology within the context of the ITU-T Transport Network 
Recommendations. This allows MPLS-TP documents to be generally 
understood by those familiar with MPLS RFCs. The definitions 
presented in this document do not provide exclusive or complete 
interpretations of the ITU-T Transport Network concepts. 


1. Abbreviations 


CE Customer Edge 

DCC Data Communication Channel 

DCN Data Communication Network 

ECC Embedded Communication Channel 
EMF Equipment Management Function 
EMS Element Management System 

GAL Generic Associated Channel Label 
LER Label Edge Router 

LSR Label Switching Router 

MCC Management Communication Channel 
MCN Management Communication Network 
ME Maintenance Entity 
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MEG Maintenance Entity Group 
MEP Maintenance Entity Group End Point 
MIP Maintenance Entity Group Intermediate Point 
MPLS Multiprotocol Label Switching 
MPLS-TP MPLS Transport Profile 
MS-PW Multi-Segment Pseudowire 
NE Network Element 
NEF Network Element Function 
OAM Operations, Administration, and Maintenance 
OSS Operations Support System 
PM Performance Monitoring 
PST Path Segment Tunnel 
PW Pseudowire 
S-PE Switching Provider Edge 
SCC Signaling Communication Channel 
SCN Signaling Communication Network 
SPME Sub-Path Maintenance Element 
T-PE Terminating Provider Edge 
TCM Tandem Connection Monitoring 
2. Terminology 


December 2013 


This section provides an overview regarding terminology used in this 


document. 


2.1. MPLS-TP Terminology Sources 


MPLS-TP terminology is principally defined in [RFC3031]. 


Other 


documents, including [RFC4397], provide further key definitions. 
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2.2. ITU-T Transport Network Terminology Sources 


The ITU-T Transport Network is specified in a number of 
Recommendations: generic functional architectures and requirements 
are specified in [ITU-T G.805], [ITU-T G.806], and [ITU-T G.872]. 
ITU-T Recommendation G.8101/Y.1355 [ITU-T G.8101] contains an 
overview of the terms and definitions for transport MPLS. 


2.3. Common Terminology Sources 


The work in this document builds on the shared view of MPLS 
requirements. It is intended to provide a source for common MPLS-TP 
terminology. In general, the original terminology is used. 


The following sources are used: 


o IETF framework and requirements RFCs: [RFC6371], [RFC6372], 


[RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031], and 
[RFC4397]. 


o ITU-T architecture and requirements Recommendations: 
[ITU-T G.8101], [ITU-T G.805], [ITU-T G.806], [ITU-T G.872], 
[ITU-T G.7710], and [ITU-T Y.2611]. 


3. Thesaurus 
3.1. Associated Bidirectional Path 


An associated bidirectional path is a path that supports traffic flow 
in both directions but that is constructed from a pair of 
unidirectional paths (one for each direction) that are associated 
with one another at the path's ingress/egress points. An associated 
bidirectional path need not be a single management and operational 
entity. The forward and backward directions are set up, monitored, 
and protected independently. As a consequence, they may or may not 
follow the same route (links and nodes) across the network. 


3.2. Bidirectional Path 


A bidirectional path refers to a path that supports traffic flow in 
two opposite directions, i.e., the forward and backward direction. 


3.3. Client-Layer Network 


In a client/server relationship (see [ITU-T G.805]), the client-layer 
network receives a (transport) service from the lower server-layer 
network (usually the layer network under consideration). 
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3.4. Communication Channel 


A Communication Channel is a logical channel between network elements 
(NEs) that can be used, e.g., for management-plane applications or 
control-plane applications. The physical channel supporting the 
Communication Channel is technology specific. See [RFC5951], 
Appendix A. 


3.5. Concatenated Segment 


A concatenated segment is a serial-compound link connection as 


defined in [ITU-T G.805]. A concatenated segment is a contiguous 
part of an LSP or MS-PW that comprises a set of segments and their 
interconnecting nodes in sequence. See also "Segment" 


(Section 3.35). 


3.6. Control Plane 


Within the scope of [RFC5654], the control plane performs transport 
path control functions. Through signaling, the control plane sets 
up, modifies, and releases transport paths and may recover a 
transport path in case of a failure. The control plane also performs 
other functions in support of transport path control, such as routing 
information dissemination. It is possible to operate an MPLS-TP 
network without using a control plane. 


3.7.  Co-Routed Bidirectional Path 


A co-routed bidirectional path is a path where the forward and 
backward directions follow the same route (links and nodes) across 
the network. A co-routed bidirectional path is managed and operated 
as a single entity. Both directions are set up, monitored, and 


protected as a single entity. A Transport Network path is typically 
co-routed. 


3.8. Data Communication Network (DCN) 


A DCN is a network that supports Layer 1 (physical layer), Layer 2 
(data-link layer), and Layer 3 (network layer) functionality for 
distributed management communications related to the management 
plane, for distributed routing and signaling communications related 
to the control plane, and for other operations communications (e.g., 
order-wire/voice communications, software downloads, etc.). 
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3.94. -Defect 


"Defect" refers to the situation for which the density of anomalies 
has reached a level where the ability to perform a required function 
has been interrupted. Defects are used as input for Performance 
Monitoring (PM), the control of consequent actions, and the 
determination of fault cause. See also [ITU-T G.806]. 


3.10. Domain 


A domain represents a collection of entities (for example, network 
elements) that are grouped for a particular purpose, examples of 
which are administrative and/or managerial responsibilities, trust 
relationships, addressing schemes, infrastructure capabilities, 
aggregation, survivability techniques, distributions of control 


functionality, etc. Examples of such domains include IGP areas and 
Autonomous Systems. 


3.11. Embedded Communication Channel (ECC) 


An ECC is a logical operations channel between network elements (NEs) 
that can be utilized by multiple applications (e.g., management-plane 
applications, control-plane applications, etc.). The physical 
channel supporting the ECC is technology specific. An example of a 
physical channel supporting the ECC is a Data Communication Channel 
(DCC) within the Synchronous Digital Hierarchy (SDH). 


3.12. Equipment Management Function (EMF) 


The equipment management function (EMF) provides the means through 
which an element management system (EMS) and other managing entities 
manage the network element function (NEF). See [ITU-T G.7710]. 


3.13. Failure 


A failure is a detected fault. A failure will be declared when the 
fault cause persisted long enough to consider that a required 
transport function cannot be performed. The item may be considered 
as failed; a fault has now been detected. See also [ITU-T G.806]. A 
failure can be used as a trigger for corrective actions. 


3.14. Fault 


A fault is the inability of a transport function to perform a 
required action. This does not include an inability due to 
preventive maintenance, lack of external resources, 


or planned 
actions. See also [ITU-T G.806]. 
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3.15. Layer Network 


"Layer network" is defined in [ITU-T G.805]. A layer network 
provides for the transfer of client information and independent 
operation of the client OAM. A layer network may be described in a 
service context as follows: one layer network may provide a 
(transport) service to a higher client-layer network and may, in 
turn, be a client to a lower-layer network. A layer network is a 
logical construction somewhat independent of arrangement or 
composition of physical network elements. A particular physical 
network element may topologically belong to more than one layer 
network, depending on the actions it takes on the encapsulation 
associated with the logical layers (e.g., the label stack) and thus 
could be modeled as multiple logical elements. A layer network may 
consist of one or more sublayers. For additional explanation of how 
layer networks relate to the OSI concept of layering, see Appendix I 
of [ITU-T Y.2611]. 


3.16. Link 


A link as discussed in this document refers to a physical or logical 
connection between a pair of Label Switching Routers (LSRs) that are 
adjacent at the (sub)layer network under consideration. A link may 
carry zero, one, or more LSPs or PWs. A packet entering a link will 
emerge with the same label-stack entry values. 


A link as defined in [ITU-T G.805] is used to describe a fixed 
relationship between two ports. 


3.17. Maintenance Entity (ME) 


A Maintenance Entity (ME) can be viewed as the association of two (or 
more) Maintenance Entity Group End Points (MEPs) that should be 
configured and managed in order to bound the OAM responsibilities of 
an OAM flow across a network or sub-network, i.e., a transport path 
or segment in the specific layer network that is being monitored and 
managed. See also Section 3.1 of [RFC6371] and Clause 6.1 of 

[ITU-T G.8113.1] and [ITU-T G.8113.2]. 


A Maintenance Entity may be defined to monitor and manage 
bidirectional or unidirectional point-to-point connectivity or point- 
to-multipoint connectivity in an MPLS-TP layer network. 


Therefore, in the context of an MPLS-TP LSP ME or PW ME, Label Edge 
Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs, 
while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs. In 
the case of an ME for a tandem connection, LSRs and S-PEs can be 
either MEPs or MIPs. 
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The following properties apply to all MPLS-TP MEs: 
- OAM entities can be nested but not overlapped. 
- Each OAM flow is associated with a unique Maintenance Entity. 


- OAM packets are subject to the same forwarding treatment as the 
data traffic, but they are distinct from the data traffic by the 
Generic Associated Channel Label (GAL). 


3.18. Maintenance Entity Group (MEG) 


A Maintenance Entity Group is defined, for the purpose of connection 
monitoring, between a set of connection points within a connection. 
This set of connection points may be located at the boundary of one 
administrative domain or a protection domain or the boundaries of two 
adjacent administrative domains. The MEG may consist of one or more 
Maintenance Entities (MEs). See also Section 3.1 of [RFC6371] and 
Clause 6.2 of [ITU-T G.8113.1] and [ITU-T G.8113.2]. 


In an MPLS-TP layer network, a MEG consists of only one ME. 
3.19. Maintenance Entity Group End Point (MEP) 


Maintenance Entity Group End Points (MEPs) are the end points of a 
pre-configured (through the management or control planes) ME. MEPs 
are responsible for activating and controlling all of the OAM 
functionality for the ME. A source MEP may initiate an OAM packet to 
be transferred to its corresponding peer MEP (called the sink MEP) or 
to an intermediate MIP that is part of the ME. See also Section 3.3 
of [RFC6371] and Clause 6.3 of [ITU-T G.8113.1] and [ITU-T G.8113.2]. 


A sink MEP terminates all the OAM packets that it receives 
corresponding to its ME and does not forward them further along the 
path. 


All OAM packets coming into a source MEP are tunneled via label 
Stacking and are not processed within the ME as they belong either to 
the client network layers or to a higher Tandem Connection Monitoring 
(TCM) level. 


A MEP in a tandem connection is not coincident with the termination 
of the MPLS-TP transport path (LSP or PW), though it can monitor its 
connectivity (e.g., counts packets). A MEP of an MPLS-TP network 
transport path is coincident with transport path termination and 
monitors its connectivity (e.g., counts packets). 
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An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP 
client-layer network. 


3.20. Maintenance Entity Group Intermediate Point (MIP) 


A Maintenance Entity Group Intermediate Point (MIP) is a point 
between the two MEPs in an ME and is capable of responding to some 
OAM packets and forwarding all OAM packets while ensuring fate 
sharing with data-plane packets. A MIP responds only to OAM packets 
that are sent on the ME it belongs to and that are addressed to the 
MIP; it does not initiate OAM messages. See also Section 3.4 of 
[RFC6371] and Clause 6.4 of [ITU-T G.8113.1] and [ITU-T G.8113.2]. 


3.21. Management Communication Channel (MCC) 


A Communication Channel dedicated to management-plane communications 
is referred to as a Management Communication Channel (MCC). 


3.22. Management Communication Network (MCN) 


A DCN supporting management-plane communication is referred to as a 
Management Communication Network (MCN). 


3.23. Monitoring 


Monitoring is applying OAM functionality to verify and to maintain 
the performance and the quality guarantees of a transport path. 

There is a need to not only monitor the whole transport path (e.g., 
LSP or MS-PW), but also arbitrary parts of transport paths. The 
connection between any two arbitrary points along a transport path is 
described in one of three ways: 


- as a Path Segment Tunnel, 
- as a Sub-Path Maintenance Element, or 
- as a Tandem Connection. 

3.23.1. Path Segment Tunnel (PST) 
A path segment is either a segment or a concatenated segment. Path 
Segment Tunnels (PSTs) are instantiated to provide monitoring of a 
portion of a set of co-routed transport paths (LSPs or MS-PWs).  PSTs 


can also be employed to meet the requirement to provide Tandem 
Connection Monitoring. See "Tandem Connection" (Section 3.23.3). 
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3.23.2.  Sub-Path Maintenance Element (SPME) 


To monitor, protect, and manage a portion (i.e., segment or 
concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be 
instantiated. A hierarchical LSP instantiated for this purpose is 
called a Sub-Path Maintenance Element (SPME). Note that by 
definition, an SPME does not carry user traffic as a direct client. 


An SPME is defined between the edges of the portion of the LSP that 
needs to be monitored, protected, or managed. The SPME forms an 
MPLS-TP Section that carries the original LSP over this portion of 
the network as a client. OAM messages can be initiated at the edge 
of the SPME and sent to the peer edge of the SPME or to a MIP along 
the SPME. A P router only pushes or pops a label if it is at the end 
of an SPME. In this mode, it is an LER for the SPME. 


3.23.3. Tandem Connection 


A tandem connection is an arbitrary part of a transport path that can 
be monitored (via OAM) independently from the end-to-end monitoring 
(OAM). It may be a monitored segment, a monitored concatenated 
segment, or any other monitored ordered sequence of contiguous hops 
and/or segments (and their interconnecting nodes) of a transport 
path. 


Tandem Connection Monitoring (TCM) for a given path segment of a 
transport path is implemented by creating a Path Segment Tunnel that 
has a 1:1 association with the path segment of the transport path 
that is to be uniquely monitored. This means that the PST used to 
provide TCM can carry one and only one transport path, thus allowing 
direct correlation between all fault-management and performance- 
monitoring information gathered for the PST and the monitored path 
segment of the end-to-end transport path. The PST is monitored using 
normal LSP monitoring. See also Section 3.2 of [RFC6371] and 

Clause 6.2.1 of [ITU-T G.8113.1] and [ITU-T G.8113.2]. 


3.24. MPLS Section 


An MPLS Section is a network segment between two LSRs that are 
immediately adjacent at the MPLS layer. 


3.25. MPLS Transport Profile (MPLS-TP) 


An MPLS Transport Profile refers to the set of MPLS functions used to 
support packet transport services and network operations. 
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3.26. MPLS-TP NE 


A network element (NE) that supports MPLS-TP functions is referred to 
as an MPLS-TP NE. 


3.27.  MPLS-TP Network 

An MPLS-TP network is a network in which MPLS-TP NEs are deployed. 
3.28. MPLS-TP Recovery 
3.28.1.  End-to-End Recovery 


MPLS-TP end-to-end recovery refers to the recovery of an entire LSP, 
from its ingress to its egress node. 


3.28.2. Link Recovery 


MPLS-TP link recovery refers to the recovery of an individual link 
(and hence all or a subset of the LSPs routed over the link) between 
two MPLS-TP nodes. For example, link recovery may be provided by 
server-layer recovery. 


3.28.3. Segment Recovery 
MPLS-TP segment recovery refers to the recovery of an LSP segment 


(i.e., segment and concatenated segment) between two nodes and is 
used to recover from the failure of one or more links or nodes. 


An LSP segment comprises one or more contiguous hops on the path of 
the LSP. [RFC5654] defines two terms: a "segment" is a single hop 
along the path of an LSP, while a "concatenated segment" is more than 
one hop along the path of an LSP. 


3.29. MPLS-TP Ring Topology 


In an MPLS-TP ring topology, each LSR is connected to exactly two 
other LSRs, each via a single point-to-point bidirectional MPLS-TP 
capable link. A ring may also be constructed from only two LSRs 
where there are also exactly two links. Rings may be connected to 
other LSRs to form a larger network. Traffic originating or 
terminating outside the ring may be carried over the ring. Client 
network nodes (such as Customer Edges (CEs)) may be connected 
directly to an LSR in the ring. 
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3.29.1. MPLS-TP Logical Ring 


An MPLS-TP logical ring is constructed from a set of LSRs and logical 
data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and 
physical data links that form a ring topology. 


3.29.2. MPLS-TP Physical Ring 


An MPLS-TP physical ring is constructed from a set of LSRs and 
physical data links that form a ring topology. 


3.30. OAM Flow 


An OAM flow is the set of all OAM packets originating with a specific 
Source MEP that measure the performance of one direction of a MEG (or 
possibly both in the special case of data-plane loopback). 


3.31. Operations Support System (OSS) 


An OSS is a system that performs the functions that support 
processing of information related to Operations, Administration, 
Maintenance, and Provisioning (OAM&P) for the networks, including 
surveillance and testing functions to support customer access 
maintenance. 


3.32. Path 
See "Transport Path" (Section 3.45). 
3.33. Protection Priority 


Fault conditions (e.g., signal failed), external commands (e.g, 
forced switch, manual switch), and protection states (e.g., no 
request) are defined to have a relative priority with respect to each 
other. Priority is applied to these conditions/command/states 
locally at each end point and between the two end points. 


3.34. Section-Layer Network 


A section layer is a server layer (which may be MPLS-TP or a 
different technology) that provides for the transfer of the section- 
layer client information between adjacent nodes in the transport-path 
layer or transport-service layer. A section layer may provide for 
aggregation of multiple MPLS-TP clients. Note that [ITU-T G.805] 
defines the section layer as one of the two layer networks in a 
transmission-media-layer network. The other layer network is the 
physical-media-layer network. 
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Section-layer networks are concerned with all the functions that 
provide for the transfer of information between locations in path- 
layer networks. 


Physical-media-layer networks are concerned with the actual fibers, 
metallic wires, or radio frequency channels that support a section- 
layer network. 


3.35. Segment 


A segment is a link connection as defined in [ITU-T G.805]. A 
segment is the part of an LSP that traverses a single link or the 
part of a PW that traverses a single link (i.e., that connects a pair 
of adjacent S-PEs and/or T-PEs). See also "Concatenated Segment" 
(Section 3.5). 


3.36. Server Layer 


A server layer is a layer network in which transport paths are used 
to carry a customer's (individual or bundled) service (may be point- 
to-point, point-to-multipoint, or multipoint-to-multipoint services). 


In a client/server relationship (see [ITU-T G.805]), the server-layer 
network provides a (transport) service to the higher client-layer 
network (usually the layer network under consideration). 


3.37. Server MEPs 


A server MEP is a MEP of an ME that is defined in a layer network 
below the MPLS-TP layer network being referenced. A server MEP 
coincides with either a MIP or a MEP in the client-layer (MPLS-TP) 
network. See also Section 3.5 of [RFC6371] and Clause 6.5 of 
[ITU-T G.8113.1]. 


For example, a server MEP can be one of the following: 

o A termination point of a physical link (e.g., IEEE 802.3), an SDH 
Virtual Circuit (VC), or OTN Optical Data Unit (ODU) for the 
MPLS-TP Section layer network, defined in [RFC6371], Section 4.1; 


o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371], 
Section 4.2; 


o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371], 
Section 4.3; or 


o An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371], 
Section 3.2. 
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The server MEP can run appropriate OAM functions for fault detection 
and notifies a fault indication to the MPLS-TP layer network. 

3.38. Signaling Communication Channel (SCC) 

A Signaling Communication Channel is a Communication Channel 
dedicated to control-plane communications. The SCC may be used for 
GMPLS / Automatically Switched Optical Network (ASON) signaling 
and/or other control-plane messages (e.g., routing messages). 


3.39. Signaling Communication Network (SCN) 


A DCN supporting control-plane communication is referred to as a 
Signaling Communication Network (SCN). 


3.40. Span 
A span is synonymous with a link. 

3.41. Sublayer 
"Sublayer" is defined in [ITU-T G.805]. The distinction between a 
layer network and a sublayer is that a sublayer is not directly 
accessible to clients outside of its encapsulating layer network and 
offers no direct transport service for a higher-layer (client) 
network. 


3.42. Transport Entity 


A transport entity is a node, link, transport path segment, 
concatenated transport path segment, or entire transport path. 


3.42.1. Working Entity 


A working entity is a transport entity that carries traffic during 
normal network operation. 


3.42.2. Protection Entity 


A protection entity is a transport entity that is pre-allocated and 
used to protect and transport traffic when the working entity fails. 


3.42.3. Recovery Entity 


A recovery entity is a transport entity that is used to recover and 
transport traffic when the working entity fails. 
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3.43. Transmission Media Layer 


A transmission media layer is a layer network, consisting of a 
section-layer network and a physical-layer network as defined in 
[ITU-T G.805], that provides sections (two-port point-to-point 
connections) to carry the aggregate of network-transport path or 
network-service layers on various physical media. 


3.44. Transport Network 


A Transport Network provides transmission of traffic between attached 
client devices by establishing and maintaining point-to-point or 
point-to-multipoint connections between such devices. A Transport 
Network is independent of any higher-layer network that may exist 
between clients, except to the extent required to supply this 
transmission service. In addition to client traffic, a Transport 
Network may carry traffic to facilitate its own operation, such as 
that required to support connection control, network management, and 
OAM functions. 


3.45. Transport Path 
A transport path is a network connection as defined in [ITU-T G.805]. 
In an MPLS-TP environment, a transport path corresponds to an LSP or 
a PW. 

3.46.  Transport-Path Layer 
A transport-path layer is a (sub)layer network that provides point- 
to-point or point-to-multipoint transport paths. It provides OAM 
that is independent of the clients that it is transporting. 

3.47.  Transport-Service Layer 
A transport-service layer is a layer network in which transport paths 
are used to carry a customer's (individual or bundled) service (may 
be point-to-point, point-to-multipoint, or multipoint-to-multipoint 
services). 


3.48. Unidirectional Path 


A unidirectional path is a path that supports traffic flow in only 
one direction. 
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4. 


Guidance on the Application of This Thesaurus 


As discussed in the introduction to this document, this thesaurus is 
intended to bring the concepts and terms associated with MPLS-TP into 
the context of the ITU-T's Transport Network architecture. Thus, it 
should help those familiar with MPLS to see how they may use the 
features and functions of the Transport Network in order to meet the 
requirements of MPLS-TP. 


Management Considerations 


Networks based on MPLS-TP require management. The MPLS-TP 
Specifications described in [RFC5654], [RFC5860], [RFC5921], 
[RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1], and [ITU-T G.7710] 
include considerable efforts to provide operator control and 
monitoring as well as OAM functionality. 


These concepts are, however, out of the scope of this document. 
Security Considerations 


Security is a significant requirement of MPLS-TP. See [RFC6941] for 
more information. 


However, this informational document is intended only to provide a 
lexicography, and the security concerns are, therefore, out of the 
Scope of this document. 
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